NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/6109

Internet Message Format | 1996-08-05 | 5.4 KB

Path: qualcomm.com!usenet
From: [e-mail] (Nasser Abbasi)
Newsgroups: comp.lang.c++
Subject: Re: What's so bad about global variables?
Date: 11 Feb 1996 10:14:44 GMT
Organization: Qualcomm Inc.
Message-ID: <4fkfik$[e-mail]>
References: <4fjtga$[e-mail]>
NNTP-Posting-Host: nabbasi.qualcomm.com
Mime-Version: 1.0
X-Newsreader: WinVN 0.93.14

In article <4fjtga$[e-mail]>, [e-mail]
says...
>
>
> Why do programmers treat like global variables as if they are the
>single most evil thing you can possibly do in a C program?
>


Well, I think the reason of not desiring to use a global variable
comes from the idea that reducing coupling between different functions
in different modules in a large program leads to a cleaner program to
debug and maintain,and that the only interaction between different
functions in a system should be through parameter passing (in OO terms,
called message passing, when the functions are part of a class object).

A global variable is a means for achieving fast exchange of information
between different parts of a program, and as we all know, there is no
free lunch in this world, one must pay a price for this, what is this
price?

2 different functions in different modules sharing a global variables
are coupled with each others in an undesirable and uncontrolled way, the
code inside one function becomes dependent on the form/structure and the
means of access of this global object, any future needs by one function
to modify some of these attribute of the shared object could also affect
the rest of program, different functions in different parts of the
program might have to change because one function needed to change its
own internal way of using the global object. (certainly something we do
not want to happen, we have coupled the way one function internally
perform processing on a global variable with the way other functions in
the system does its own internal processing on the same variable, a bad
side effect of sharing the use of global variables).

Also if one function wants to change the protocol by which it
uses/access this global variables, all other parts of the program might
be affected. One must start looking through the source code looking for
all places where this global variable is being used, which could be
spread all over the place, in addition one must try to figure if the
access is read/write/update by the context, this is a messy and
unorganized way of developing software, there is not one place can look
at to determine the access mechanism, compare that with argument passing
(message passing) where one knows by looking at the function definition
what type of access the arguments are being passed as. (in Ada terms, IN,
IN OUT, OUT), in C++ one can apply the access modifier "const"
to the parameters, assuming no one is casting the constness way).

Another problem with using a shared variable shows up in multithreaded
applications, when the global variable has to be protected by a critical
section else disorder might rule. (this might not have to be done, it
depends on the application use of the global variable),  Look for example
at the  problem in using errno for example in multithreaded applications
in C.

Not all uses of global variables are bad, It depends on the scope of the
global variable,  In C terms, having a static variable inside a file
declared outside any function in the file (i.e at outer level) gives that
variable a global scope over all the functions inside that file only, but
that variable is still hidden from the rest of the program, functions in
different files/modules can not access this variable, this is just fine,
since functions inside that one file are supposed to have strong cohesion
between them, they by definition should be cooperating functions, and so
can all coordinate accessing this file level global variable. (This is
similar to methods inside one class having access to private members of
the class).

Also, many times in system programming, shared memory sections are used
for fast communications between different processes, (this is considered
one of the fastest way to exchange data between processes), this is
another form of global variable use, but at the process level, here also
additional code must be written so that controlled and synchronized
access to this shared memory is achieved, usually by using system
services.

One might say, but I have a variable that a higher level routine has
updated, and a low level routine needs to access, and passing this down
through few layers of software until it reaches the low level routine is
a waste of resources and time, when one can just update a global area of
memory, and let the low level routine just read it directly, resulting is
speed of execution.

Well, for me, this is sacrificing design integrity of a program for sake
of immediate gain of speed, there is most likely a better design where
this need can be removed, I also think that one must first come up with a
clean design, then worry about performance issues after that, as much as
possible.

Bad effects of using global variables shows up most in large programs, in
small program, one might be able to use program level global variables
and not see any bad side effect to its use, but it is a good idea to
start with the habit of not using global variable even in small programs
(less that 5 to 10 K lines).

IMHO

Nasser